ULs reserved under certain Nodes

All / some UL values under certain Nodes have already been “claimed” or “reserved” by certain Standards yet no indication of this is given in the Registers.

For example, not all of the possible UMID ULs (under UMID Nodes) have been listed in the Registers due to the huge number of combinations.

So, it is necessary to take a little care when choosing UL values for new entries – as long as a sensible location is chosen then there should not be an issue.

ULs with sub-ids/bytes greater than 0x7f

Background

The bulk of each UL is made-up of a sequence of integers called “sub-ids”. However, a UL is typically represented as a sequence of 16 bytes. To convert from a sequence of sub-ids to a sequence of bytes, “primitive encoding” is used as defined in SMPTE ST 298.

In this scheme, each sub-id with a value less than 128 is encoded directly as one byte. However, a sub-id with a value of more than 127 (0x7f) requires more than one byte of the encoded UL. This is because only 7-bits of each byte are used to encode the integer value of a sub-id.

Virtually all ULs that have ever been registered are made up of sub-ids that are less than, or equal to, 127 (0x7f) in value. This means that in practice virtually all encoded ULs only contain bytes that are less than, or equal to, 0x7f.

Sometimes it is necessary to have a large number of entries under a Node in a Register. It is straightforward to accommodate 127 entries under a single Node. However, when more than 127 entries are required a UL is needed with a sub-id greater than 127 (0x7f) in value.

Guidance for Registers Submission authors

ULs containing sub-ids greater than 0x7f are permitted (in accordance with SMPTE ST 298 etc).

Registers Submission authors are discouraged from using ULs that contain sub-ids which could be “potentially problematic” when encoded into a UL: these are sub-ids which are encoded with a 0x00 byte (because some documents have said / implied that this causes the termination of a UL).

For the avoidance of doubt: ULs encoding values that do not require the full 16-bytes will of course continue to be padded with trailing zero bytes.

Example

This means that under the MXF Group / Class node (urn:smpte:ul:060e2b34.027f0101.0d010101.01010000) the next entry after:

urn:smpte:ul:060e2b34.027f0101.0d010101.01017f00 – where the final sub-id is 127 (note: the encoded UL is padded with a trailing zero byte so that 16 bytes are used in total)

should be:

urn:smpte:ul:060e2b34.027f0101.0d010101.01018101 – where the final sub-id is 129 (note: the encoding of this sub-id uses the final two bytes)